Guidelines: Business WorkerTopics
Explanation
A business worker represents an abstraction of a human that acts within the business. A business worker object interacts with other business worker objects and manipulates business entity objects in order to realize a business use-case instance. We use worker individual as a synonym for business worker object. A worker is instantiated ("manned") when the workflow of its corresponding use-case instance is started or, at the latest, just in time for the person doing the job to play his role in the use-case instance. A worker object often "lives" (the person is engaged) as long as the business use case executes. Attributes
An object normally holds different pieces of information that describe some of its characteristics. Such pieces of information can either be described implicitly in the textual description of the objectÆs class, or modeled explicitly as an attribute of the class. An attribute is of a certain type. An attribute has a name, preferably a noun that describes the attributeÆs role in relation to the class. An attribute type can be more or less primitive, starting from a simple number or string. Different classes can have attributes with identical structures. Those attributes should share a description; that is, they should share attribute type. An attribute may be more or less tangible. For instance, you might model as an attribute the information that a certain business worker must keep in mind as he executes a business use case. Another example of a potential attribute is a checklist that a business worker should follow. Note: You should only model attributes to make a class more understandable! Operations
An operation of a business worker class represents a specific activity to be performed by an individual of that class. The operation of a business worker is initiated by a message from another worker individual or from an actor. An operation has a name and, optionally, parameters. An operation describes a task a worker may be asked to perform. It is initiated by a message. A business worker represents a role played by an employee. To perform the job in a use case, the person acting as a business worker performs one, or several activities. When designing a business workerùthat is, when defining what a business worker must be able to do in order to produce the desired results of a business use caseùyou have two alternatives. You can either:
Each operation is defined by a name, which should tell its purpose, and optionally, a number of parameters. The parameters specify what an object of the class should expect to receive from an object that is requesting support or making an access, and what the object will provide when the operation has been performed. As an example, you can give parameters that reflect when a business worker should take a step in the worker operation, or when he should access a certain business entity by initiating one of the business entityÆs operations. Parameters can also represent more or less tangible things that are handed over. Operations can be defined informally, or in more detail, depending on the importance or required level of detail in a use case. A "more detailed" description might describe a behavior sequence that tells which attributes and relationships are dealt with during its performance, how objects of other classes are contacted, and how it is terminated. Business Worker Characteristics
The characteristics of a business worker should cover the following topics:
This type of information is only useful to capture for "human" business workers. Checkpoints
for Good Business Workers
Copyright ⌐ 1987 - 2000 Rational Software Corporation |
Rational Unified
Process |